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PREFACE 


Air  Force  Global  Weather  Center  (AFGWC)  produces  a  global  cloud  analysis  called  Real-Time  Nephanalysis 
(RTNEPH).  The  purpose  of  US  AFETAC— 86/001  (Revised  November  1996),  RTNEPHAFCCC  Climatic  Da¬ 
tabase  Users  Handbook  No.  1,  is  to  provide  users  with  information  on  the  history,  production,  and  content  of  the 
RTNEPH  climatic  database. 
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Chapter  1 

INTRODUCTION 


1.1  Purpose  of  the  Handbook.  This  handbook 
provides  users  of  the  Real-Time  Nephanalysis 
(RTNEPH)  Climatic  Database  with  information  on 
its  history,  production,  and  content.  The  handbook 
will  also  explain  the  RTNEPH  analysis,  discuss 
RTNEPH  processing  and  quality  control,  and  describe 
the  Low/Middle/High  Type/ Amount  (LMHT/A) 
Database  (a  derivative  of  RTNEPH). 

12  RTNEPH  History  and  Background.  Aug.  1, 
1983,  theAir  Force  Global  Weather  Center  (AFGWC), 
at  Offutt  AFB,  Neb.,  started  production  of  a  global 
cloud  analysis  called  the  RTNEPH.  The  new  cloud 
analysis  replaced  its  predecessor,  the  Three- 
dimensional  Nephanalysis  (3DNEPH),  a  detailed 
description  of  which  can  be  found  in  AFGWC 
Technical  Memorandum  78-002.  A  detailed 
description  of  the  RTNEPH  model  is  given  in 
AFGWC/TN-88/001 ,  the  AFGWC  Automated  Real- 
lime  Cloud  Analysis  Model. 

AFGWC  produces  RTNEPH  data  every  3  hours,  eight 
times  a  day,  for  operational  forecasting  and  other 
customer  support  applications.  The  analyses  for  each 


day  are  sent  to  AFCCC’s  Operation  Location  A  (OL- 
A)  in  Asheville,  N.C.,  for  inclusion  in  the  USAF 
climatological  database.  OL-A  started  building  the 
RTNEPH  Climatic  Database  with  the  Jan.  1,  1984 
data. 

RTNEPH  has  several  distinct  advantages  over  the 
3DNEPH.  Its  four  floating  cloud  layers,  for  example, 
give  it  greater  vertical  resolution  than  could  be 
provided  by  3DNEPH’s  15  fixed  layers.  Other 
improvements,  such  as  better  input  algorithms  and 
the  use  of  weighting  factors  for  age  of  data  and 
conventional  vice  satellite  data,  have  also  greatly 
improved  the  analysis.  The  RTNEPH  also  includes 
visibility,  present  weather  intensity,  and  information 
about  the  kind  of  input  data  used  to  produce  the  cloud 
analysis. 

13  Questions  and  Comments.  Address  questions 
or  comments  on  the  RTNEPH  Climatic  Database  to 
AFCCC,  151  Patton  Ave.  Room  120,  Asheville,  NC 
28801-5002.  For  more  information  call  DSN  266- 
3100,  commercial  (704)  271-4235. 


1 


RTNEPHAFCCC  CLIMATIC  DATABASE  USERS  HANDBOOK  NO.  I 


Chapter  2 


DESCRIPTION  OF  THE  REAL-TIME  NEPH ANALYSIS  (RTNEPH) 


2.1  The  Eighth-Mesh  Grid.  The  AFGWC  RTNEPH 
model  produces  cloud  cover  detu  for  the  entire  globe, 
using  all  available  conventional  data  (surface,  upper- 
air  and  aircraft)  and  satellite  (DMSP  and  NOAA)  data 
to  produce  an  analysis  every  3  hours  (at  0000, 0300, 
0600, 0900, 1200, 1500, 1 800  and  2100  GMT).  Each 
analysis  is  divided  into  two  hemispheres:  Northern 
and  Southern.  On  a  1  to  3  million  polar  stereo-graphic 
projection,  each  hemisphere  is  divided  into  64 
numbered  boxes  as  shown  by  the  following 
illustrations.  Note  that  100  is  added  to  each  of  the 
Southern  Hemisphere’s  boxes.  The  four  comer  boxes 


in  each  hemisphere  (Northern:  1, 8, 57, 64;  Southern: 
101, 108, 157, 164)  are  not  used  in  the  analysis  because 
they  are  completely  “off-hemisphere.”  Each  remaining 
box  is  divided  into  4,096  individual  areas  (64  x  64), 
laid  out  on  a  grid  called  the  “1/8  mesh”  or  eighth- 
mesh”  grid.  Grid  points  are  about  25  nautical  miles 
apart.  Each  grid  point  within  a  box  is  identified  by  an 
“F’  (lateral)  and  a  “F’  (vertical)  coordinate.  “I-l”  is 
the  upper-left  comer  of  each  box— “I”  increases  to 
the  right.  “J-1”  is  also  the  upper-left  comer,  but ‘T’ 
increases  downward.  Any  grid  point  on  the  globe  can 
be  located  by  its  grid  box  and  its  I  and  J  coordinates. 
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With  60  boxes  in  each  hemisphere  and  4,096  grid 
points  in  each  box,  there  are  245,760  grid  points  per 
hemisphere.  But  only  196,014  of  the  Northern 
Hemisphere  grid  points  contain  analysis  data;  in  the 
Southern  Hemisphere,  only  195,805.  The  extra  209 
grid  points  in  the  Northern  Hemisphere  are  located 
exactly  on  the  equator.  All  the  remaining  49,000-plus 
grid  points  per  hemisphere  are  considered  to  be  “off- 
hemisphere.” 

More  complete  information  on  the  eighth-mesh  grid 
is  available  in  AFGWC/TN-79/003,  Map  Projections 
and  Grid  Systems  for  Meteorological  Applications, 
March  1981. 


2.2  Database  Elements.  Each  RTNEPH  eighth-mesh 
grid  point  contains  the  following  climatic  database 
elements: 

•  Present  weather 

•  Surface  visibility 

•  Time  flag  for  age  of  data 

•  Total  cloud  amount  (percentage  of  earth  in 
grid  point  area  covered  by  clouds) 

•  Source  flags  for  layer  data 

•  Four  floating  cloud  layers  that  contain: 

1- layer  cloud  amount 

2- layer  cloud  type 

3- layer  cloud  base 

4- layer  cloud  top 

•  Diagnostic  information 
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DESCRIPTION  OF  THE  REAL-TIME  NEPHANALYSIS  (RTNEPH) 


2.3  Data  Used.  All  satellite  and  conventional  data 
available  within  each  grid  point  area  used  in  the 
analysis. 

2.3.1  Satellite  Data.  The  Defense  Meteorological 
Satellite  Program  (DMSP)  acquires  and  processes 
meteorological  satellite  data  from  DMSP  satellites. 
Although  there  is  a  capability  to  input  National 
Oceanographic  and  Atmospheric  Administration 
(NOAA)  polar  orbited  imagery  directly  in  RTNEPH, 
it’s  not  included  routinely  because  of  limited  computer 
resources.  Both  DMSP  and  NOAA  satellites  provide 
infrared  and  visual  imagery  for  the  daylight  side  of 
the  globe,  and  infrared  imagery  on  the  night  side.  The 
first  step  of  the  analysis  process  integrates  all  available 
satellite  data  to  produce  an  RTNEPH  satellite  analysis 
for  a  grid  point.  Although  RTNEPH  can  operate 
without  satellite  data,  the  resultant  analysis  would  be 
very  limited. 

2.3.2  Conventional  Data.  In  the  second  step,  AFGWC 
collects  all  available  conventional  data  (surface  jmd 
radiosonde)  from  the  Automated  Weather  Network 
(AWN)  and  integrates  it  into  the  RTNEPH 


conventional  analysis,  producing  a  “best  report”  for  a 
given  grid  point.  In  some  areas  of  the  world  (North 
America  and  Western  Europe,  for  example), 
conventional  data  is  abundant.  Grid  points  in  these 
regions  may  contain  numerous  surface  reporting 
stations.  For  example,  grid  point  1-13,  J-51  in  Box 
45  of  the  Northern  Hemisphere  (latitude  40.67  north, 
longitude  73.99  west)  offers  five  possible  sources  of 
surface  data:  Newark  International  Airport,  N.J.;  John 
F.  Kennedy  IntemationalAirport,  N.Y.;  and  FtUlden, 
N.Y.  The  AFGWC  RTNEPH  model,  in  “decision  tree” 
fashion,  selects  which  observations,  and  which 
elements  within  those  observations,  will  be  used  to 
build  a  “best  report”  type  of  observations. 

2.3.3  Merge  Processor.  The  final  automated  step  in 
producing  an  RTNEPH  analysis  is  merging  the  outputs 
of  the  satellite  and  conventional  analyses.  The  merge 
processor  decides  which  data  to  use  from  the  two 
inputs  to  produce  the  final  product.  If  recent 
conventional  and  satellite  data  is  not  available  for  the 
RTNEPH  analysis,  AFGWC  will  “persist”  the 
RTNEPH  data  from  the  previous  hour’s  analysis. 
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Chapter  3 

THE  RTNEPH  CLIMATIC  DATABASE 

3.1  Tape  Specifications.  AFCCC/OL-A’s  RTNEPH  climatic  database  (Box-Time  File)  tape 
specifications  are  as  follows: 

cartridge,  3787 IBPI,  labeled,  sort  = 

BX-YR-MO-DA-HR  Record  #. 
record  length  14,344  bytes,  unblocked, 

10  tapes/month/hemisphere,  6  boxes/tape 

Binary  —  8-bit  bytes 

Eight  J  rows  per  record  —  (512  grid  points) 

Eight  records  per  box- YR-MO-DA-HR 


3.2  RTNEPH  Climatic  Database  Format. 
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CHAPTERS 


DATA  HELD  BYTE  LOCATION 


BX  1 

YEAR  2 

MO  3 

DA  4 

HR  5 

#  6 

j  7 

IND  8 


PWX  9 

VSBY  10 

TF  11 

TA  12 

SFl  13 

SF2  14 

SF3  15 

SF4  16 

AMT  17 

TYP  18 

BAS  19 

TOP  20 


CODE  DEFINITION 

Box  (2-7,  9-56, 58-63,  102-107,  109-156,  158-163) 

Year 

Month 

Day 

Hour 

Record  #  (1-8  of  box  in  byte  1) 

J-coordinate  (1,  9, 17,  25,  33, 41, 49,  57) 

Indicator:  OL-A  did/did  not  persist  record 
1  =  Persisted  by  OL-A 

0  =  Not  persisted  by  OL-A  (if  record  was  missing  or  deleted 
by  quality  control  procedures) 

*  Present  Weather  (00-99, 255;  WMO  Code  4677) 

*  Visibility  (00-50, 56-99, 255;  WMO  Code  4377) 

Time  flag  (00-255,  see  3.2.1) 

Total  cloud  amount  (0-100  percent) 

Data  source  flags-Layer  1  (see  3.2.2) 

Data  source  flags-Layer  2  (see  3.2.2) 

Data  source  flags-Layer  3  (see  3.2.2) 

Data  source  flags-Layer  4  (see  3.2.2) 

Layer  1  cloud  amount  (0-103,  see  3.2.3) 

Layer  1  cloud  type  (0-10, 25,  see  3.2.4) 

Layer  1  cloud  base  (0-255,  see  3.2.5) 

Layer  1  cloud  top  (0-255,  see  3.2.5) 


Note:  Elements  from  bytes  17-20  are  repeated  for  layer  2,  layer  3  and  layer  4. 


FLAGS  33-36 


Diagnostic  flags  (see  3.2.6) 


data  for  grid  POINTS  2-512;  37-14,344  Same  as  for  grid  point  1 


28  bytes  x  512  points  =  14,336  bytes 

*  Prior  to  June  23, 1986,  at  2100Z,  missing/not  reported  present  weather  and  visibility  data  is  indicated  by  code 
zero;  after  that  data/time.  Code  255  is  used  (see  4.4). 


3.2.1  Time  Flag  for  the  Grid  Point.  This  reflects  the  time  of  the  newest  data  at  the  grid  point. 


CODEVALUE 

0-229 

230 

231-254 

255 


DEFINITION 

Indicates  age  of  data  used  in  RTNEPH  analysis  (in  hours). 

Indicates  that  data  used  in  RTNEPH  analysis  is  more  than  229  hours  old. 
Indicates  that  data  used  in  the  analysis  is  for  a  data  time  after  analysis  time  (code 
value  -  230). 

Indicates  that  data  used  in  RTNEPH  analysis  are  more  than  24  hours  after 
analysis  time. 
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THE  RTNEPH  CUMATIC  DATABASE 


3.2.2  Source  Flags  for  Cloud  Layer  Data.  An  added  three  indicates  the  combination  of  the  one 

and  two. 


BIT  DEHNinON 

1  Low  cloud  type  persisted 

2  Layer  cloud  base  estimated 

3  Layer  cloud  top  estimated 

4  Best  report  from  radiosonde  data 

5  Not  used 

6  Best  report  from  surface  data 

7  Visual  satellite  data  used  as  input 

8  IR  satellite  data  used  as  input 

Note:  If  the  bit  is  set  on,  the  source  condition  exited. 

3.2.3  Layer  Cloud  Amount.  Layer  cloud  amount  code 
range  is  0-103,  with  the  layer  cloud  amount  rounded 
up  to  the  next  highest  5  percent.  Additional  values 
to  the  layer  cloud  amount  indicate  the  following; 

An  added  one  indicates  a  thin  cloud  layer. 

An  added  two  indicates  the  cloud  layer  was  derived 
from  merging  two  cloud  decks. 


3.2.4.  Cloud  Types. 

CODEVALUE 

0 

1 

2 

3 

4 

5 

6 

7 

8 

9 

10 
25 


CLOUD  TYPE 
Clear 

Cumulonimbus 

Stratus 

Stratocumulus 

Cumulus 

Altostratus 

Nimbostratus 

Altocumulus 

Cirrostratus 

Cirrocumulus 

Cirras 

Unknown 


Note:  If  all  four  RTNEPH  layers  contain  clouds,  and 
a  ground  base  layer  of  fog  is  located  beneath  the  lowest 
reported  cloud  deck,  the  RTNEPH  will  indicate  the 
fog  by  adding  10  to  the  cloud  type  code  for  layer  4 
(the  lowest  layers  contain  clouds  and  a  ground  base 
layer  of  fog  is  located  beneath  the  lowest  reported 
cloud  deck  and  the  codes  for  the  other  cloud  layers 
are  unchanged. 


9 


CHAPTERS 


3.2.5  Cloud  Heights  (Bases  and  Tops) 

CODE  VALUES  DEFINrnONS 

0-200  30-meter  increments  for  0-6,000  meters  MSL. 

201  -253  300-meter  increments  for  6,300-21 ,900  meters  MSL, 

MSL  height  =  (code  -  200)  x  300  6,000. 

254  Greater  than  21 ,900  meters. 

255  Height  not  available. 

3.2.6  Diagnostic  Flags. 


BYTE  BIT 
1  1 

2 

3 

4 

5 

6 

7 

8 

2  1-3 


4- 8 

3  1 
2 

3 

4 

5 

6 

7 

8 

4  1 
2 

3 

4 

5- 6 
7-8 


DEHNinON 

Not  received  (bogus  flag). 

Best  report  flag-a  conventional  report  was  included  in  this  point. 

Spread  data-data  from  a  best  report  was  spread  to  this  point. 

Visual  satellite  data  was  included  in  this  analysis. 

IR  satellite  data  was  included  in  this  analysis. 

Low-level  cloud  has  been  persisted  past  normal  data  cutoff  time. 

Identifies  that  although  the  visual  satellite  observed  cloudy,  the  point  is  marked 
clear  for  lack  of  other  supporting  data. 

Fog/haze  superseded  by  other  weather  elements  in  present  weather. 

Bits  indicate  the  age  of  the  oldest  conventional  data  used  in  this  report.  This 
hour  indicator  will  be  used  in  situations  when  a  conventional  low-level  cloud 
report  was  persisted  while  new  satellite  data  was  used  as  input  for  the  analysis. 
Not  used. 

Not  used. 

The  “best  report”  contained  radiosonde  data. 

Not  used. 

The  “best  report”  contained  surface  data. 

Ice- water  point  was  iced  over. 

Snow— snow  flag  was  set. 

Tropics— point  is  in  the  tropics. 

IR  daylight  quarter  orbit  (q.o.)-this  IR  q.o.  was  in  daylight. 

IR  sunside  quarter  orbit-this  point  was  on  the  sunward  side  of  the  IR  q.o. 

Visual  daylight  quarter  orbit-this  visual  q.o.  was  in  daylight. 

Visual  sunside  quarter  orbit-the  visual  data  was  on  the  sunward  side  of  the 
visual  q.o. 

Sunglint-visual  data  for  this  point  fell  in  the  sunglint  cone. 

IR  satellite  ID  the  IR  satellite  ID  minus  1.  This  is  an  internal  ID  (1-4)  used  to 
select  tuning  parameters  at  AFGWC. 

Visual  satellite  ID  the  visual  satellite  ID  minus  1. 
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OL-A  DATA  PROCESSING  AND  QUALITY  CONTROL 


4.1  Steps  in  RTNEPH  Data  Processing  at  OL-A: 

•  Check  readability-inventory  synoptic  data. 

•  Quality  control  data. 

•  Build  persist  file  and  RTNEPH  daily  synoptic 
data  file. 

•  Process  1  month  of  RTNEPH  box-time  data. 

•  Build  hemispheric  file. 

•  Build  persist  file  and  monthly  LMHT/A 
hemispheric  data  file. 

•  Process  monthly  histogram  data  from 
LMHT/A  hemispheric  data  file. 

4J2  Quality  Control  at  AFGWC.  RTNEPH  quality 
control  at  AFGWC  consists  of  manual  interface  with 
data  via  a  “pre-bogus”  map  generated  twice  a  day. 
Meteorologists  look  for  problem  areas  on  these  maps, 
correcting  problems  manually  by  “bogusing,”  and 
returning  the  corrected  areas  to  the  system.  Bogusing 
may  include  any  one  or  all  the  elements  produced  by 
the  RTNEPH  system.  RTNEPH  analysis  data  for  a 
particular  point  is  reviewed  up  to  four  times  a  day. 
Problem  areas  that  were  bogues  by  AFGWC 
forecasters  are  persisted  for  a  minimum  of  4  hours  (a 
tumable  factor)  and  may  persist  for  up  to  12  hours  if 
there  is  no  new  data  for  the  point.  A  post-bogus  map 
is  then  generated  and  reviewed  by  analysts  to  verify 
modifications.  If  the  bogus  is  verified,  the  workfile  is 
cleared  to  allow  room  for  future  bogusing  data.  If  the 
bogus  is  not  verified,  the  unmodified  fields  are  restored 
and  a  decision  is  made  as  to  whether  or  not  to 
reaccomplish  the  bogus.  Any  questionable  data  (due 
to  satellite  problems,  etc.)  are  classified  as  either 
“unusable”  or  “usable  with  consideration,”  according 
to  box-day-hour. 

43  Quality  Control  at  OL-A.  RTNEPH  quality 
control  at  OL-A  consists  of  a  series  of  automated  gross 
quality  control  checks.  These  “gross”  checks  ensure 
that  the  data  contains  no  obvious  errors.  If  a  grid 
point  is  in  error,  all  the  elements  for  that  grid  point 
are  set  equal  to  missing  (i.e.,  code  255,  all  bits  turned 
on).  From  January  1984  to  January  1988,  OL-A 
received  (from  AFGWC)  a  list  of  box-day-hours  that 
were  “unusable”  or  “usable  with  consideration.”  Those 


box-day-hours  listed  as  “unusable”  were  deleted  from 
the  database,  and  the  deleted  records  are  filled  with 
data  from  the  previous  synoptic  hovir.  Those  deemed 
“usable  with  consideration”  are  documented  on 
AFGWC  Form  12,  Synoptic  RTNEPH  QC  Log,  in 
our  files,  and  remain  in  the  climatic  database. 

4.3.1  RTNEPH  Gross  Quality  Control  Algorithms. 

ID  Field  Checks: 

1. )  Limits  for  Fields: 

Box:  NH  =  2-7, 9-56,  58-63 

SH  =  102-107, 109-156,  158-163 
Year:  Numeric 
Month:  1-12 
Day:  1-31 

Hour:  00,03,  06,  09, 12, 15, 18,  21 
Record#  1-8 

J-Coordl-9, 17.  25,  33,  41,  49,  57 

2. )  Records  in  sequence-checkbox-year-month-day- 
hour-record  #  sequence. 

3. )  Record  #  and  J-coordinate  in  agreement-(J-coord 
=  (rec#  X  8)  -  7). 

4. )  Missing  records. 

5. )  Missing  hours. 

4.3.2  Data  Field  Checks: 

1. )  All  bits  turned  on  (I’s)  for  off-globe  points. 

2. )  Valid  values  of  present  weather:  00-99,  255. 

3. )  Valid  values  of  visibility:  00-50,  56-99,  255. 

4. )  Valid  values  of  total  cloud  amount:  00-100. 

5. )  Valid  values  of  layer  cloud  amount:  0-1-3,  except 

1,2,3  and  values  that  are  multiples  of  (5  -1). 

6. )  Valid  values  of  layer  cloud  type:  00-10, 25  -  if  all 
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four  layers  contain  cloud  data,  then  limits  for  layer 
four  are  00-20,  25. 

7. )  If  present  weather  greater  than  49  and  less  100, 
total  cloud  amount  must  not  equal  0. 

8. )  If  data  is  persisted  more  than  24  hours,  present 
hour’s  data  must  be  exactly  the  same  as  the  previous 
hour’s. 

9. )  No  individual  cloud  amount  can  be  greater  than 
total  cloud  amount  +7.  (i.e.,  for  one  cloud  layer,  total 
cloud  amount  might  be  26  percent;  layer  cloud  amount 
would  then  be  reported  as  30  and  if  that  cloud  deck  is 
thin  and  merged  (see  Paragraph  3.2.3),  layer  cloud 
amount  could  be  reported  as  33  while  total  cloud 
amount  would  be  reported  as  26. 

10. )  If  any  layered  data  element  except  base  height  is 
equal  to  zero,  then  all  elements  for  that  layer  must 
also  equal  zero. 

11. )  If  (10)  is  true,  then  all  layers  following  must 
also  equal  zero. 

12. )  Unused  bits  of  diagnostic  flag  b3^s  are  required 
to  be  set  “off.” 

13. )  The  top  of  a  cloud  layer  must  not  be  less  than 
the  base  of  the  same  layer. 

14. )  Layer  cloud  base  is  converted  to  height  AGL, 
then  checked  to  see  if  each  cloud  type  is  in  the  right 
category  (low,  middle,  high).  The  terrain  disc  file  is 
used  to  convert  MSL  code  to  AGL.  Following  are 
cloud  types  and  their  cloud  base  limits: 

Types  Base  Heights  fmeters-AGLi 

1,2,3,4,11,12,13,14  0-1,980 

5,  6,  7, 15,  16,  17  1,981-5,028 

8,9,10,18,19,20  GE  5,029 

15. )  Valid  values  of  cloud  top:  0-254. 

16. )  Valid  values  of  cloud  base:  0-254. 

17. )  Sum  of  the  layer  cloud  amounts  is  not  less  than 
the  total  cloud  amount. 


18.)  Each  succeeding  layer’s  cloud  base  is  less  than 
immediately  preceding  layer  cloud  base  (i.e.  layer  2 
cloud  base  less  than  layer  1  cloud  base). 

Note;  If  any  of  the  above  checks  are  failed  (except  1 
and  12,  all  elements  for  the  grid  point,  except  source 
flag,  are  changed  to  missing  (all  bits  turned  on). 

4.4  Documented  Problems.  The  RTNEPH  has 
several  documented  problems  resulting  either  from 
processing  errors  or  from  weaknesses  in  the  RTNEPH 
model  itself.  In  the  future,  some  of  these  will  be 
corrected  as  improvements  are  made  to  the  model  and 
to  the  weather  satellite’s  observing  capabilities. 

Coastline  Misinterpretation.  RTNEPH  can  over¬ 
interpret  clouds  along  the  southwest  Asian  coastline. 
The  cause  appears  to  lie  in  the  temperature  gradients 
over  the  area. 

Missing  Present  Weather  and  Visibility  Coding.  Prior 
to  June  23, 1986,  at  2100Z,  code  “0”  (zero)  was  used 
for  missing/not  reported  present  weather  and/or 
visibilities.  After  June  23,  1996  at  2100Z,  the  code 
for  “missing”  was  changed  to  255  (all  bits  “on”). 

Cloud  Interpretation  Deficiencies.  The  satellite 
sometimes  has  difficulty  in  detecting  thin  cirrus 
clouds.  It  also  provides  poor  interpretation  of  stratus 
clouds  in  the  absence  of  conventional  data.  In  the 
snow-  and  ice-covered  regions  around  the  poles, 
satellites  sometimes  have  trouble  making  the 
distinction  between  low  clouds  and  snow  or  ice  fields; 
the  result  is  under-reporting  of  low  clouds. 

Missing  SH  RTNEPH  Data.  All  December  1984 
Southern  Hemisphere  (SH)  RTNEPH  data,  boxes  102- 
112  and  153-163  were  set  to  “missing”  for  all 
elements. 

Degraded  RTNEPH  Data.  The  RTNEPH  data  from 
Dec.  6, 1988,at0600ZthroughDec.7, 1988,at2100Z 
was  degraded.  Total  cloud  amounts  were  good,  but 
there  were  problems  with  individual  layers. 

Unusable  RTNEPH  Data.  RTNEPH  data  from  Jan. 
2, 1990,  at  0200Z  through  Jan.  4, 1990,  at  1200Z  were 
unusable  due  to  software  problems  during  production. 
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Persisted  SH  RTNEPH  Data.  SH  boxes  102  to  105 
for  all  eight  synoptic  hours  for  July  7,  1985,  were 
persisted. 

Missing  Data.  Box  45  contains  no  conventional  data 
from  Dec.  5, 1988,  at  OOOOZ  through  April  6, 1989  at 
2100Z. 

Incorrect  Cloud  Bases.  In  the  data  from  January  1 9  84 
through  November  1989,  bases  of  cumulus  and 
stratocumulus,  especially  for  over-water  points,  are 
often  reported  as  zero  meters. 

Lack  of  Aircraft  Data.  AFGWC/TN— 88/001  states 
that  aircraft  reports  encoded  in  RECCO,  ICAO,  and 
USAF  aircraft  report  formats  will  be  used  by  the 
RTNEPH  processor.  Due  to  decoding  problems, 
however,  no  aircraft  reports  of  any  kind  have  been 
included  in  RTNEPH  data  since  January  1984. 

Incorrect  Default  Cloud  Thickness.  Default  cloud 
thickness  (used  to  model  in  cloud  tops  or  bases  as 
defined  in  AFGWC/TN-88/001)  have  not  been  used 
consistently  since  January  1984. 

Greater  than  100  percent  Coverage  at  Same  Level. 
When  multiple  cloud  layers  are  reported  at  overlapping 
levels,  the  sum  of  the  cloud  amounts  of  the  individual 
layers  often  exceed  100  percent. 

Spread  Data.  RTNEPH  points  over  land  contain  a 


large  percentage  of  spread  data.  Points  that  surround 
a  station  that  reports  regularly  contain  spread  data 
nearly  all  the  time.  In  some  regions,  especially  in 
CONUS,  most  RTNEPH  reports  are  of  spread  data. 

Spread  Data.  When  the  spreading  technique  is  used 
in  areas  with  few  reporting  stations,  the  result  is  large 
blocks  of  identical  data.  These  blocks  have  sharp 
boundaries  that  often  contrast  sharply  with  adjacent 
RTNEPH  points  based  on  satellite  data. 

Persisted  Data.  Over- water  areas  near  the  equator 
often  contain  large  percentages  of  persisted  data. 

Default  Cloud  Thicknesses.  Cloud  thicknesses  used 
in  modeling  in  cloud  tops  and  bases  are  not  stratified 
for  latitude  or  seasonal  variation. 

Conventional  vs.  Satellite  Data.  Because  of  inherent 
differences  between  conventional  surface  and  satellite 
observations,  there  are  significant  statistical  differences 
in  the  types  and  amounts  of  cloud  coverage  reported 
by  each. 

Conflicting  Data  Elements.  When  surface 
observations  and  satellite  data  is  merged,  unusual 
combinations  can  result.  For  example,  stratus, 
cumulus  layers,  or  even  fog  can  be  reported  beneath 
large  thunderstorms.  Visibility  or  present  weather 
reported  may  not  always  agree  with  the  amounts  or 
types  of  clouds  reported. 
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THE  LMHT/A  DATABASE 


5.1  Content.  The  LMHT/A  (low/middle/high  cloud 
types  and  amounts  and  total  cloud  amount)  database 
consists  of  cloud  data  derived  from  the  RTNEPH 
database.  Low  clouds  are  considered  to  be  from  0  to 
1,980  meters  AGL,  middle  from  1,981  to  5,028  meters 
AGL,  and  high  above  5,028  meters  AGL.  Cloud  types 
are  categorized  as  follows: 


Cloud  Type 

LMHT/A  CateeorY 

RTNEPH  CODE* 

Cumulonimbus  Low 

1.11 

Stratus 

Low 

2.12 

Stratocumulus 

Low 

3.13 

Cumulus 

Low 

4.14 

Altostratus 

Middle 

5.15 

Nimbostratus 

Middle 

6.16 

Altocumulus 

Middle 

7.17 

Cirrostratus 

High 

8.18 

Cirrocumulus 

High 

9.19 

Cirrus 

High 

10.20 

*  When  all  four  RTNEPH  layers  contain  clouds  and 
there  is  ground-based  fog,  the  fog  will  be  indicated 
by  adding  10  to  the  lowest  layer’s  type.  If  less  than 
four  layers  contain  clouds,  the  fog  becomes  the  lowest 
layer  and  no  changes  are  made  to  the  other  cloud  layer 
types. 

5.2  Database  Build  Procedure.  The  LMHT/A 
database  build  procedures  validate  total  cloud  amount 
and  RTNEPH  cloud  layers  for  each  grid  point  to  ensure 
that  total  cloud  amount,  layer  cloud  amount,  layer 
cloud  base,  and  layer  cloud  top  are  not  missing  (cloud 
types  can  be  missing).  If  any  one  of  these  elements, 
except  cloud  type,  is  missing,  then  low,  middle,  and 
high  types  and  amounts  are  set  missing,  as  is  the  total 
cloud  amount.  Validated  RTNEPH  layers  are  grouped 
in  LMHT/A  categories  by  cloud  type,  and  all  layers 
within  a  category  are  combined  as  shown  below. 

LMHT/A  cloud  type  is  coded  to  identify  each 
RTNEPH  cloud  type  reported  within  an  LMHT/A 
category.  For  example,  RTNEPH  cloud  layer  data 


for  a  grid  point  might  consist  of  the  following: 


LYR 

MIN  BASE  MAXTOPCLD 

TYPECLD 

AMT 

1 

200 

215 

8 

65 

2 

100 

150 

5 

51 

3 

40 

80 

4 

35 

4 

10 

35 

3 

32 

Layer  1,  with  RTNEPH  cloud  type  8  (cirrostratus),  is 
encoded  as  LMHT/A  high  category  type  3;  layer  2, 
with  RTNEPH  type  5  (altostratus),  is  encoded  as 
LMHT/A  middle  category  cloud  type  2;  layers  3  and 
4,  with  RTNEPH  cloud  types  4  (cumulus)  and  3 
(stratocumulus),  are  both  included  in  the  LMHT/A 
low  category  as  cloud  type  6  (stratocumulus  and 
cumulus).  The  following  cloud  code  conversion  tables 
show  the  various  combinations  of  RTNEPH  cloud 
types  possible  within  a  low,  middle,  or  high  category, 
along  with  the  corresponding  LMHT/A  codes. 


Low  Clouds 

LMHT/A 

Cloud 

RTNEPH 

Code 

Type 

Code 

1 

Stratocumulus  (SC) 

3 

2 

Stratus  (ST) 

2 

3 

Cumulus  (CU) 

4 

4 

Cumulonimbus  (CB) 

1 

5 

SC  and  ST 

2,3 

6 

SC  and  CU 

3,4 

7 

SC  and  CB 

1,3 

8 

ST  and  CU 

2,4 

9 

ST  and  CB 

1,2 

10 

CU  and  CB 

1,4 

11 

SC,  ST,  and  CU 

2,3,4 

12 

SC,  ST,  and  CB 

1,2,3 

13 

SC,  CU,  and  CB 

1,3,4 

14 

ST,  CU,  and  CB 

1,2,4 

15 

SC,  ST,  CU,  and  CB 

1,  2,  3, 4 

99 

Cloud  type  missing 

25 

0 

No  cloud  present 

0 

15 
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Middle  Clouds 


LMHT/A 

Cloud 

RTNEPH 

Code 

Type 

Code 

1 

Altocumulus  (AC) 

7 

2 

Altostratus  (AS) 

5 

3 

Nimbostratus  (NS) 

6 

4 

AC  and  AS 

5,7 

5 

AC  and  NS 

6,7 

6 

AS  and  NS 

5,6 

7 

AC,  AS,  and  NS 

5,  6,7 

99 

Cloud  type  missing 

25 

0 

No  cloud  present 

0 

High  Clouds 

LMHT/A 

Cloud 

RTNEPH 

Code 

Srpe 

Code 

1 

Cirrus  (Cl) 

10 

2 

Cirrostratus  (CC) 

9 

3 

Cirrostratus  (CS) 

8 

4 

Cl  and  CC 

9,  10 

5 

Cl  and  CS 

8,  10 

6 

CC  and  CS 

8,9 

7 

Cl,  CC,  and  CS 

8,  9, 10 

99 

Cloud  type  missing 

25 

0 

No  cloud  present 

0 

An  LMHT/A  category  (low,  middle,  and  high)  amount 
is  derived  by  combining  all  RTNEPH  layer  amounts 
within  each  category. 


When  all  RTNEPH  layers  are  within  one  category, 
the  amount  is  taken  directly  from  the  RTNEPH  total 
cloud  amount. 

When  one  RTNEPH  layer  is  in  an  LMHT/A  category, 
as  in  the  middle  and  high  categories  of  the  example 
given  earlier,  the  LMHT/A  category  amount  is  taken 
directly  from  the  RTNEPH  layer  amount  and  adjusted 
down  to  the  nearest  5  percent. 


When  multiple  (but  not  all)  RTNEPH  layers  constitute 
an  LMHT/A  category,  as  in  the  low  category  of  the 
example,  the  RTNEPH  layer  amounts  are  combined 
using  the  following  equation: 

Sum  layer  =  layer  a  +  [1  -  (layer  a  x  .01)]  x 

layer  b  x  .75,  where  layer  a  is  greater  than  or 

equal  to  layer  and  units  are  in  percent. 

The  above  algorithm  is  applied  first  to  the  two 
RTNEPH  layers  with  the  highest  bases.  When  three 
layers  are  reported,  the  summed  amount  of  the  first 
two  layers  and  the  third  RTNEPH  layer  are  then 
processed  in  a  second  iteration  of  the  above  equation. 

If  the  summed  amount  exceeds  the  RTNEPH  total 
cloud  amount,  RTNEPH  total  cloud  amount  is  used 
instead.  To  sum  the  two  low  categories  in  the  above 
example,  35  percent  for  layer  a  and  30  percent  for 
layer  b  was  used: 

Sum  layer = 35  +  [1  -  (35  x  .01)]  x  30  X  .75  = 

50  percent. 

When  the  summation  of  all  LMHT/A  layer  amounts 
is  less  than  the  RTNEPH  total  cloud  amount,  the 
LMHT/A  layer  amounts  that  were  derived  with  the 
above  equation  will  be  increased  by  computing  the 
difference  between  the  RTNEPH  total  cloud  amount 
and  the  summation  of  the  LMHT/A  layer  amounts, 
then  increasing  each  layer  by  a  proportional  amount 
(i.e.,  the  ratio  of  the  layer  amount  to  the  summation 
amount)  or  the  difference. 

Finally,  layer  cloud  amounts  are  coded  from  0-20  as 
shown  in  the  cloud  amount  conversion  table  next  page. 
The  LMHT/A  total  cloud  amount  is  taken  directly 
from  RTNEPH  total  cloud  amount  and  converted  to 
LMHT/A  database  code  from  the  table.  The  sum  layer 
of  50  percent  from  the  example  above  would  be 
converted  to  code  10. 


THE  LMHT/A  DATABASE 


Cloud 

Amount 

(percentage) 

LMHT/A 

Code 

Cloud 

Amount 

(percentage) 

LMHT/A 

Code 

0 

0 

51  thru  55 

11 

1  thru  5 

1 

56  thru  60 

12 

6  thru  10 

2 

61  thru  65 

13 

11  thru  15 

3 

66  thru  70 

14 

16  thru  20 

4 

71  thru  75 

15 

21  thru  25 

5 

76  thru  80 

16 

26  thru  30 

6 

81  thru  85 

17 

31  thru  35 

7 

86  thru  90 

18 

36  thru  40 

8 

91  thru  95 

19 

41  thru  45 

9 

96  thru  100 

20 

46  thru  50 

10 

Invalid 

99 

5.3  LMHT/A  Database  Format.  The  LMHT/A  data 
is  structured  by  hemisphere  (hemispheric  file). 

5.3.1.  Grid  System.  The  hemispheric  file  is  on  the 
AFGWC  512  X  512  subset  of  the  eighth-mesh 
reference  grid  for  the  Northern  and  Southern 
hemispheres. 

5.2.2.  Tape  Specifications:  Cartridge,  37871  BPI 
labeled,  sort  =  hemis-yr-mo-da-hr,  record  length  = 
14,356  bytes,  unblocked,  8-bit  bytes,  3  tapes/hemis- 
mo.  This  data  will  be  built  only  upon  customer 
request.  Please  allow  extra  time  for  this  to  be 
accomplished  when  ordering. 


5.3.3  Format: 


DATA 

FIELD 

#  BYTES 

BYTE  LOG 


BINARY 


1  III 

m 

m 

■ 

H 

■ 

L 

L 

M 

N 

u 

H 

■1 

u 

L 

K 

Bl 

n 

H 

M 

E 

H 

Q 

H 

J 

c 

c 

c 

C 

H 

C 

B 

B 

C 

C 

H 

H 

C 

H 

M 

YEAR 

0 

H 

R 

512 

OPEN 

n 

D 

D 

A 

11 

n 

D 

n 

u 

D 

H 

■1 

■ 

■ 

■ 

3 

BIS 

H 

H 

n 

B 

fl 

fl 

H 

H 

H 

■ 

H 

■ 

■ 

HP 

■ 

■ 

n 

■ 

■ 

HI 

NOTE:  THE  ELEMENTS  FROM  BYTE  LOCATIONS  21-27  ARE  REPEATED  2048  TIMES. 


1  GRID  POINT  2048  \ 

L 

L 

M 

M 

H 

H 

T 

C 

C 

C 

C 

C 

C 

C 

T 

A 

T 

A 

T 

A. 

A 

1 

1 

1 

J__ 

J_ 

1 

1 

14350 

14356 

Data  Field 

Bvte  Location 

Code  Definition 

Format 

HEM 

1 

N  =  N  Hemis,  S  =  S  Hemis 

Ascn 

G/L 

2 

G  =  GMT,L  =  LST 

Ascn 

YEAR 

3-6 

1983,  1984,  etc. 

AScn 

MO 

7-8 

01-12  =  JAN-DEC 

AScn 

DA 

9-10 

01-31 

AScn 

HR 

11-12 

00,  03.  06, ....  21 

AScn 

J512 

13-15 

1,  5.  9,  13, ....  509 

AScn 

OPEN 

16-20 

zeroes 

AScn 

Data  for  grid  point  1: 

LCT 

21 

Low  cloud  type  (00-15,  99) 

BINARY 

LCA 

22 

Low  cloud  amount  (00-20,  99) 

BINARY 

MCT 

23 

Mid-cloud  type  (00-07,  99) 

BINARY 

MCA 

24 

Mid-cloud  amount  (00-20,  99) 

BINARY 

HCT 

25 

High  cloud  type  (00-07,  99) 

BINARY 

HCA 

26 

High  cloud  amount  (00-20,  99) 

BINARY 

TCA 

27 

Total  cloud  amount  (00-20,  99) 

BINARY 

Data  for  grid  points  2  -  2,048;  28  - 

14,356.  Same  as  for  grid  point  1 

BINARY 

7  bytes  x  2,048  points  =  14,336  bytes 

Notes:  1.  Code  99  =  Missing/unknown  data. 

2.  Cloud  amount  codes — see  cloud  amount  conversion  table. 
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5.4  LMHT/A  Histogram  Database.  The  LMHT/A  unblocked,  8-bit  bytes,  2  tapes/hemi-mo. 
histogram  database  includes  a  histogram  of  the  number 

of  occurrences  of  each  LMHT/A  code  value  of  month-  5,4.2  Format  The  monthly  histogram  data  may  be 

hour.  combined,  at  some  future  date,  to  include  up  to  8  years 

of  data.  Cell  ranges  for  low,  middle,  and  high  cloud 
5,4,1,  Tape  Specifications:  Cartridge  tape,  37,871  types  and  amounts  are  given  in  the  tables  of  the  end 
BPI,  sort  =  hemis-mo-hr,  record  length  =  1 5 ,796  bytes,  of  this  section. 


DATA 

FIELD 

#  BYTES 

BYTE  LOG 


NOTE:  THE  ELEMENTS  FROM  BYTE  LOCATIONS  53-175  ARE  REPEATED  128  TIMES. 


Data  Field 

Bvte  Location 

Code  Definition 

Format 

HEM 

1 

N  =  N  Hemis,  S  =  S  Hemis 

Ascn 

G/L 

2 

G  =  GMT.L  =  LST 

ASCn 

MO 

3-4 

01-12  Jan-Dec 

Ascn 

HR 

5-6 

00,  03,  06, ...  21  ASCn 

J512 

7-9 

001, 512  Ascn 

Start  I 

10-12 

001,  129,  257,  385 

AScn 

IND 

13 

1  =  Days  with  clouds  of  a  ASCII 
certain  category 

OPEN 

14-16 

Zeroes 

AScn 

YRS 

17-32 

Actual  years  included  in 
histogram  84,  85, ... 

AScn 

Blank  =  Missing 

OPEN 

33-48 

00,  00, ... 

Ascn 

OBSCNT 

49-52 

Number  of  total  observations 

Ascn 

Data  for  Grid  Point  1: 
Low  cloud  type  (LCT) 


17  types/1  byte  each 

53-69 

0-248  maximum  counts 

BINARY 

Low  cloud  amount  (LCA) 

22  amounts/a  byte  each 

70-91 

0-248  maximum  counts 

BINARY 

Mid-cloud  type  (MCT) 

9  types/1  byte  each 

92-100 

0-248  maximum  counts 

BINARY 

Mid-cloud  amount  (MCA) 

22  amounts/1  byte  each 

101-122 

0-248  maximum  counts 

BINARY 

High  cloud  type  (HCT) 

9  types/1  byte  each 

123-131 

0-248  maximum  counts 

BINARY 

High  cloud  amount  (HCA) 

22  amounts/1  byte  each 

132-153 

0-248  maximum  counts 

BINARY 

Total  cloud  amount  (TCA) 

22  amounts/1  byte  each 

154-175 

0-248  maximum  counts 

BINARY 

Data  for  Grid  Points  2-128 

176-15,796 

Same  as  for  Grid  Point  1 

BINARY 

123  bytes  x  128  points  =  15,744 

Notes:  1.  Code  99  =  Missing/unknown  data. 

2.  Cloud  amount  codes  00-20;  see  tables. 
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THE  LMHT/A  DATABASE 


Histogram  Cell  Number  and  Code  for 
Low  Cloud 


Histogram 

Code 

Cell  No. 

Value 

Cloud  Tvoes 

1 

0 

No  low  cloud 

2 

1 

Stratocumulus  (SC) 

3 

2 

Stratus  (ST) 

4 

3 

Cumulus  (CU) 

5 

4 

Cumulonimbus  (CB) 

6 

5 

SC  +  ST 

7 

6 

SC  +  CU 

8 

7 

SC  +  CB 

9 

8 

ST  +  CU 

10 

9 

ST  +  CB 

11 

10 

CU  +  CB 

12 

11 

SC  +  ST  +  CU 

13 

12 

SC  +  ST  +  CB 

14 

13 

SC  +  CU  +  CB 

15 

14 

ST  +  CU  +  CB 

16 

15 

SC  +  ST  +  CU  +  CB 

17 

99 

Type  unknown 

Hist(^am  Cell  Number  and  Code  for 

Middle  Cloud 

Histogram 

Code 

Cell  No. 

Value 

Cloud  Types 

1 

0 

No  middle  cloud 

2 

1 

Altocumulus  (AC) 

3 

2 

Altostratus  (AS) 

4 

3 

Nimbostratus  (NS) 

5 

4 

AC  +  AS 

6 

5 

AC  +  NS 

7 

6 

AS  +  NS 

8 

7 

AC  +  AS+NS 

9 

99 

Type  unknown 

Histogram  Cell  Number  and  Code  for  High  Cloud 


Histogram 

Code 

Cell  No. 

Value 

Cloud  Tvoes 

1 

0 

No  high  cloud 

2 

1 

Cirrus  (Cl) 

3 

2 

Cirrocumulus  (CC) 

4 

3 

Cirrostratus  (CS) 

5 

4 

CI  +  CC 

6 

5 

CI  +  CS 

7 

6 

cc  +  cs 

8 

7 

Cl  +  CC  +  CS 

9 

99 

Type  unknown 

Histogram  Cell  Number  and  Code  for  All  Amounts 

Histogram 

Code 

Cell  No. 

Value 

Cloud  Tvoes 

1 

0 

0 

2 

1 

1-5 

3 

2 

6-10 

4 

3 

11-15 

5 

4 

16-20 

6 

5 

21-25 

7 

6 

26-30 

8 

7 

31-35 

9 

8 

36-40 

10 

9 

41-45 

11 

10 

46-50 

12 

11 

51-55 

13 

12 

56-60 

14 

13 

61-65 

15 

14 

66-70 

16 

15 

71-75 

17 

16 

76-80 

18 

17 

81-85 

19 

18 

86-90 

20 

19 

91-95 

21 

20 

96-100 

22 

99 

amount  unknown 

